The automobile industry has spent the last ten years evolving standards around which intelligent vehicle-vehicle (V2V) communications technology can be integrated into new products and deployed in conjunction with roadside infrastructure that will transform the way vehicles operate and co-operate, on the roadways.
Following the recommendation of the Intelligent Transportation Society of America (ITSA) in 2002, the IEEE created a task group in 2004 with the mandate of amending the IEEE 802.11 wireless LAN specification in order to accommodate the mobility, speed and range of vehicular network nodes. The group produced an amended specification entitled IEEE 802.11p in 2007 (incorporated herein by reference).
In 802.11p, network nodes are referred to as stations. They are either mobile, which are called On-Board Units (OBU) or Roadside Service Units (RSU). The architecture of IEEE 802.11p is intended to ensure that both OBU's and RSU's have the flexibility to support a wide scope of applications related to road safety, traffic management and roadside infrastructure. This is accomplished within a framework called WAVE (Wireless Access Vehicular Environment). The WAVE architecture, shown in FIG. 2, encompasses the 802.11p amendment as well as the new specifications (all incorporated herein by reference):                IEEE 1609.1 Resource Manager        IEEE 1609.2 Security Services        IEEE 1609.3 Network and Transport Services (Layers 3 and 4 of OSI)        IEEE 1609.4 Multichannel operation        FIG. 2 (from FIG. 2 of Roberto A. Uzcátegui, Guillermo Acosta-Marum, “WAVE: A Tutorial,” IEEE Communications Magazine, May 2009, pp. 126-133) is a representation of the complete WAVE protocol stack running in either an OBU or an RSU. Although not explicitly shown in FIG. 2, at the PHY (physical) layer, the medium is sub-divided into 7 channels: 1 control channel (CCH) and 6 “service” channels (SCH).        
This framework does not specify any of the typical applications that ultimately represent the end-user objectives of the Intelligent Vehicle Highway System (IVHS), such as vehicle-vehicle safety alerts, electronic toll collection, parking control and traffic signalization. In conjunction with the Society of Automotive Engineers (SAE) a standardized set of safety alert messages has been defined for enabling such functions as collision avoidance, lane change notification and brake application notification, and IEEE 1609.3 requires such messages to be transmitted on the control channel (CCH) But the broad range of other applications which can be supported by the WAVE architecture and have yet to be specified or, in some cases, even defined, will be achieved by a process that comprises the following steps:                An RSU or an OBU station that provides a service should advertise it with a WAVE Service Advertisement (WSA). WSAs are transmitted on the control channel (CCH). This includes, among other parameters, the specification of the service channel (SCH) on which the service is offered.        An OBU station that wants to use a service should monitor the SCH on which is offered.        
These simple mechanisms provide the basic ad-hoc networking building blocks allowing OBU stations to cooperate in achieving road-safety objectives. Note that this same mechanism applies in exactly the same fashion, without distinction, in the case of an RSU interacting with OBUs. This provides the foundation for electronic tolling, parking control, road signage and intelligent traffic signalization.
WAVE Short Message Protocol (WSMP). One of the basic elements of the WAVE protocol stack, defined in IEEE 1609.3, is a mechanism for delivery of Basic Safety Messages. The set of such messages is defined in SAE J2735 (incorporated herein by reference) and is intended to support the following safety alert and vehicle autonomous driving mechanisms:                Blind spot warning        Cooperative adaptive cruise control        Cooperative collision warning:        Cooperative forward collision warning        Emergency vehicle at scene warning        Lane change warning.        
WSMP is specified to operate over the control channel (CCH).
User Interface. It is currently anticipated that WAVE-enabled vehicles will be available from automotive OEMs by Model Year 2016. Such products will incorporate some form of display, either integrated into the vehicle dashboard or into the windshield as a Heads-up display (HUD), that presents the Basic Safety Messages to the driver in a safe, effective manner. The term “HUD” will henceforth be used in this document to refer to either a screen integrated into the vehicle dashboard or overlaid on the windshield in a way that does not obstruct the driver's field of vision.
Neighbor Discovery: A New WAVE Service. In U.S. patent application Ser. No. 13/022,101 (incorporated herein by reference), it is envisioned that V2V communication based on the ad-hoc networking specifications of IEEE 802.11 can be rendered more effective if all vehicles maintain a real-time picture of the position, heading, and speed of all vehicles around them. By doing so, each vehicle can establish a set of neighboring vehicles from which notifications of driving maneuvers, such as sudden braking or lane changes, can be judged to represent potential threats. The neighborhood of any vehicle changes dynamically, and the IEEE 802.11 channel on which monitoring is carried out, changes according to dynamically changing conditions on the road, as would be the case on exiting one freeway to enter another.
In this system, all vehicles are required to broadcast their GPS location and heading, at frequencies that provide for this information at least several times a second. Within the WAVE framework, messages containing the requisite information would constitute a service offered by each OBU. The channel on which the messages are transmitted is identified in the WAVE Service Announcement (WSA), sent on the CCH, by an RSU controlling access to a particular segment of roadway, and neighboring OBUs should listen to that channel in order to make use of the service.
IEEE 1609 specifies that WAVE Short Message Protocol (WSMP) messages are high priority notifications and should be sent over the control channel (CCH). It would therefore be conceptually possible to implement a Neighbor Discovery (ND) (This should not to be confused with the concept of Neighbor Discovery specified in ICMPv6. “Neighborhood” in the latter context is topological and does not encompass a geographic (i.e. GPS) component.) mechanism which is restricted to use of the CCH. However, this would increase the contention for the single channel, leading to degradation in reliability of the service. The mechanism envisioned in U.S. patent application Ser. No. 13/022,101 is therefore the following:                An OBU entering an intelligent roadway (or highway) receives a service announcement (WSA) on the CCH issued by the RSU (Roadside Unit) located on the entrance ramp.        The service announcement would specify the service channel (SCH) on which Neighbor Discover (ND) announcements can be received.        The OBU would be required to fully “participate” in this service, i.e. issue ND announcements on the specified SCH. At the same time, it listens to this channel to discover its neighbors and posts the received information, including GPS and heading of neighboring vehicles, to the HUD.        The RSU monitors the specified SCH for ND announcements in order to register each new OBU entering the roadway.        
This mechanism presupposes that entry to all intelligent highways is controlled by roadside infrastructure. In this scenario, service channels would be allocated to specific segments of roadway and remain unchanged. Channel allocation would be predetermined for each roadway so as to minimize the possibility of two roadways in geographic proximity using the same channel and hence reducing the potential for channel contention, particularly in high volume scenarios (traffic congestion). On entry, if the OBU is currently transmitting ND announcements on another SCH, it should continue to do so until it has received confirmation from the RSU that its current geo-position places it unambiguously on the roadway controlled by that RSU. The converse applies on exit. Once it has received the confirmation from the RSU, it may notify its (former) neighbors that it is leaving the neighborhood.
However, beyond the goal of minimizing channel contention, the concept of a vehicle “neighborhood” based on Neighbor Discovery operating on judiciously allocated service channels, is important to establish whether Basic Safety Messages (issued on the Control Channel) are coming from vehicles in the same neighborhood. For instance, two vehicles on two roadways at different elevations might, due to greater levels of error in GPS altitude than in horizontal position measurement, appear to be in the same neighborhood, whereas one is moving on the service road, and the other on an elevated or below grade highway. The geo-position of one vehicle may appear to put it directly in front of the other so that Basic Safety Message from it would be interpreted as requiring collision-avoidance behavior whereas they are not even on the same roadway. These kinds of ambiguities can only be resolved if each OBU can determine at any moment the neighborhood of vehicles in which it is operating and from which Basic Safety Messages are relevant.
System Redundancy. OBUs should monitor all service channels to ensure that changes in the neighborhood are detected in the event of malfunctioning RSU (roadside service units) or communications errors have resulted in dropped messages. An OBU can therefore discover when it has either entered or left a freeway by matching its own location and heading with Neighbor Discovery messages being received on a service channel which is different than the one on which it is currently operating. This provides an important degree of system redundancy and ensures that failure to communicate with an RSU on entry or exit will be self-correcting.
Automotive Telemetry. As envisioned in U.S. patent application Ser. No. 13/022,101, a minimal network of RSUs is important for WAVE-enabled vehicles to navigate through a road network that includes intelligent roadways. But since the WAVE protocol stack incorporates UDP (User Datagram Protocol) and TCP/IPv6 (Transmission Control Protocol/Internet protocol, version 6), as shown in FIG. 2, this creates the potential for generic Internet-based communications with any WAVE-enabled vehicle within range of an RSU.
For purposes such as monitoring driver behavior, remote automotive diagnostics, position tracking, and geofence violation (a geo-fence is a virtual perimeter for a real-world geographic area), a protocol inspired by SNMP (Simple Network Management Protocol. See Internet Engineering Task Force RFC 1157) is defined in U.S. Pat. No. 6,263,268, and U.S. Pat. No. 7,593,999 (both incorporated herein by reference). This technology, called Automotive Telemetry Protocol (ATP), envisions each device on-board a vehicle as a Server (or managed device), capable of asynchronous event reporting to a plurality of Clients, each of which are authenticated using public/private key encryption, and capable of responding to GET (requests for data) or SET (configuration) commands issued by a Client. The notion of a Diagnostic Information Base (DIB), corresponding to the role of a Management Information Base (MIB) in SNMP, ensures that all ATP communications between Server and Client should reference specific elements of the DIB and enables authorization for access to the DIB to be granted or denied to Clients, with respect to individual elements of the DIB.
Hence, ATP Clients, using UDP/IPv6, may interact with ATP Server functionality embedded in OBUs. However, if wireless communications with a vehicle is entirely dependent on the WAVE roadside infrastructure to reach vehicles, then two problems arise:                Mobile-originated asynchronous event reports (mobile-originated asynchronous event reports are transported by INFORM messages, which are defined in SNMP as Protocol Data Units (PDUs) which emanate from the managed device and require acknowledgement by the remote management system (Client)) cannot reach the client(s) authorized to receive them until the vehicle is within range of an RSU and has acquired an IPv6 network address. The importance of receiving event reports in “real-time” (in this context, the term “real-time” implies that the event communication is received more or less within a few seconds of the time it occurs) varies with the nature of the remote Client entity. For instance, it may not be critical for insurance companies monitoring driver behavior, whereas the acquisition of data in real-time may be essential to an automotive service technician who wants to initiate a remote diagnostic session with the OBD-II (On-board diagnostic) bus as soon as a diagnostic trouble code (DTC) is reported to it via ATP.        Mobile-terminated communications initiated by a client, such as a GET or SET command, cannot reach the managed device (OBU) unless is it currently shares an 802.11p data link with an RSU. In other words, again, it should be within range of WAVE roadside infrastructure.        
The present invention envisions mechanisms to ensure that an OBU enabled for ATP can overcome these limitations.